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SPACE EXPERIMENT DEVELOPMENT PROCFSS 

James F. DePauw 
NASA Lewis Research Center 
Cleveland, Ohio 

This paper describes a process for developing space experiments that utilize 
the Shuttle. The role of the Principal Investigator is described as well as 
the Principal Investigator's relation with the project development team. 

The paper describes the sequence of events from an early definition phase 
through the steps of hardware development. The major interactions between the 
hardware development program and the Shuttle integration and safety activities 
are also shown. Some lessons learned are listed along with references of 
potential value to experimenters lacking Shuttle experience. 


The presentation is directed to people with limited Shuttle experiment 
experience. The objective is to summarize the development process, discuss 
the roles of major participants, and list some lessons learned in our short 
experience. Two points should be made at the outset. First, no two projects 
are the same so the process varies from case to case. I only hope to convey 
some principles here to help you find your way through the "system." Second, 
my recent experience has been mostly with Code EN/Microgravity Science and 
Applications Division (MSAD). This presentation is heavily influenced by the 
system evolving there. 


OVERVIEW 


0 INTRODUCTION 
0 ORGANIZATIONAL ELEMENTS 
0 PRINCIPAL INVESTIGATOR ROLE 
0 DEVELOPMENT ROLE 
0 DEVELOPMENT APPROACHES 
0 FLOW CHART AND MILESTONES 
0 LESSONS LEARNED 

0 REFERENCES 
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INTRODUCTION 

0 MANY CATEGORIES EXIST FOR SPACE EXPERIMENTS 

0 SCIENCE VS. TECHNOLOGY 
0 LARGE VS. SMALL 
0 CARRIERS AND LOCATIONS 

- MIDDECK LOCKERS/CABIN ENVIRONMENT 

- MPESS/BAY ENVIRONMENT 

- GAS CANS 

- SPACELAB 

- SPACELAB PALLET 

- ETC. 

0 DIFFERENT SPONSORS USE DIFFERENT PROCESSES 
0 MOST EXPERIMENTS ARE COSTLY 
0 MOST ARE LONG-TIME COMMITMENTS 

Figure 2 


lhis introductory slide enumerates some of the variables that a space 
experiment developer encounters. This is compounded by system and personnel 
changes that occur at different organizations over the life of a project. It 
is understandable that each project proceeds through the system differently. 
On the positive side, there is much documentation available. Many precedents 
and good examples exist. The fact that many experiments have flown provides 
assurance that it is possible to succeed. 

ORGANIZATIONAL ELEMENTS 



NSTS 
CODE M 
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NSTS 
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The major organizational elements for an OAST experiment are shown. This 
should be viewed as a theoretical model. In practice, much informal 
networking among various elements is needed to accomplish the project. 

Headquarters organizations are shown on the top tier. The sponsoring 
organization usually funds the Principal Investigator (PI) activity separately 
from the project development activity so the autonomy of each can be 
preserved. Integration of the experiment into the National Space 
Transportation System (NSTS) has usually been delegated by Code R to Code EM. 
They, in turn, fund a mission manager and supporting organization at the 
Johnson Space Center (JSC), Marshall Space Flight Center (MSFC), or Goddard 
Space Flight Center (GSFC), to integrate the experiment with the carrier, 
other experiments, and other elements of the NSTS. Eventually, interaction 
with the Shuttle operators of Code M and their supporting Centers is required. 


PI ROLE AND ACTIVITIES 
0 RESPONSIBLE FOR THE EXPERIMENTAL IDEA 
0 EXPLORE IDEA VIA ANALYSIS 
0 DEMONSTRATE CONCEPT VIA GROUND TEST 
0 JUSTIFY THE NEED FOR SPACE TEST 
0 DEFEND THE EXPERIMENT IN REQUIRED "PEER" REVIEWS 
0 GENERATE REQUIREMENTS DOCUMENT AND EDUCATE DEVELOPERS 
0 PRESENT EXPERIMENT AT REQUIREMENTS REVIEW 
0 MONITOR DEVELOPMENT TO INSURE TECHNICAL INTEGRITY 
0 ANALYZE AND REPORT RESULTS 

Figure 4 
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The Principal Investigator is usually the prime mover for the endeavor. He 
conceives the idea. He explains it, defends it, and watches over it until the 
end when he evaluates results and publishes the findings. Some of the 
principal PI activities are listed. 

The task of specifying requirements is always a sensitive one. The PI 
typically desires state-of-the-art measurements and accommodations to get the 
best experiment. These requirements drive cost and schedule and in general, 
affect the ability to develop the system. It is important for the PI and the 
development team to agree early on appropriate requirements. 

DEVELOPMENT ROLE AND ACTIVITIES 
0 ITERATE REQUIREMENTS WITH P.I. 

0 DEVELOP PROJECT PLAN (COST, SCHEDULE. ETC.) 

0 DEVELOP FLIGHT HARDWARE TO MEET REQUIREMENTS 
0 KEEP P.I. UP-TO-DATE ON PROGRESS AND PROBLEMS 
0 CONDUCT MISSION OPERATIONS 

0 COORDINATE MISSION INTEGRATION, SAFETY. MANIFESTING. ETC. 


Figure 5 


Though the PI, in most cases, is very capable, he may not have the skills, 
organization, or the desire to develop and integrate the hardware with the 
space transportation system. That is the contribution of the development 
organization whose activities are summarized on this slide. 


DEVELOPMENT APPROACH OPTIONS 
0 USE OR MODIFY EXISTING FACILITY 
0 DEVELOP NEW HARDWARE 

- PI TAKES FULL RESPONSIBILITY 

- EXECUTES LITTLE TO MOST OF PROGRAM 

- CONTRACTS FOR REMAINDER 

- PI TAKES SCIENTIFIC RESPONSIBILITY ONLY 

- LETS ANOTHER SOURCE SUPPLY HARDWARE 

Figure 6 

192 


i 



There are several options for approaching the development of the experiment. 

A simple approach is to develop an experiment that uses an existing facility. 
That could give the PI team instant access to an experienced support staff 
that could carry out the experiment quickly and efficiently. However, that 
approach constrains the team. 

A more comprehensive experiment may require that new hardware be developed. 
The PI can develop as little or as much as his situation dictates. 
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The process starts with a definition phase containing the analysis, 
breadboarding, and ground testing that spawns the experiment. When the idea 
is thought to be viable, the PI documents the experiment background, 
objectives, justification, and engineering requirements so that an engineering 
team can generate flight hardware design concepts. 

A list of the critical technology issues to be addressed in the concept design 
phase of the program is useful. Cost and schedule information is needed on 
(a) the concept design phase of the program and (b) the total program. The 
estimate for (a) will, of course, be more accurate than the estimate for (b). 
The culmination of this effort is a Requirements Review (RR) involving the PI 
and hardware development organizations, the sponsoring organization, and any 
reviewers deemed appropriate. 

If the RR is successful and funding is obtained, the project group continues 
with the conceptual design. Enough engineering should be done in the concept 
design phase so that an assessment of the feasiblility can be made. The key 
science and development issues should be demonstrated by test or analysis, 
thus providing a sound foundation upon which to base a project. 

During the concept design phase, the Experiment Requirements Document is 
negotiated and refined between the PI and engineering organizations so that at 
the Concept Review ( CR) . a mutually acceptable document is available. 

NOTE : In the Code EN program, RR and CR are called Conceptual Design Review 

(CoDR) and Preliminary Requirements Review (PRR), respectively. 
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The Fo rm 100 is necessary to obtain NSTS organization support; it should be 
processed and signed as the conceptual design takes shape. The Project Office 
submits a draft to Headquarters which then arranges needed support. 

As you complete the conceptual design, submit a cost and schedule estimate for 
the entire project as part of a project plan . The project plan is an 
important agreement between the sponsor and the project organization that 
documents funding, schedule, and other critical project specifics. 

Succeeding development activities are shown along the development line. The 
CR is followed by a design phase leading to a Prelimin ar y Design Review that 
will enable approval to proceed with detailed design, the Criti cal Design 
Review culminates with the approval to fabricate hardware, etc. The typical 
hardware development milestones are shown in relative to the NSTS integration 
and safety reviews. 

(Note that the scale for NSTS milestones does not apply to the hardware 
development milestones.) 
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We at Lewis have some history of space experiments and launch vehicle 
accomplishments. We are relative newcomers to Shuttle experiment 
development. In spite of that, we have learned some lessons that may be 
useful . 

The P.T. and the development teams must develop mutual understanding to 
resolve differences promptly and amiably in order to keep the program on a 
single, focused path. 

Documentation and interpretations are sometimes inconsistent; therefore, 
investigators must be thorough in exploring questionable areas with NSTS 
personnel . 

Thorough testing at the highest system-level practical can add confidence of 
success. Such testing can also compensate for shortcuts taken at parts, 
components, and subsystem levels. 


LESSONS LEARNED 


0 KEEP THINGS SIMPLE 

0 REVIEWS TEND TO IMPROVE BUT COMPLICATE THE EXPERIMENT CONCEPT 

0 P.I. AND DEVELOPER MUST DEVELOP MUTUAL UNDERSTANDING 

0 PROJECTS ARE LONG AND COSTLY 

(A GENUINELY INTERESTED CORE GROUP IS NEEDED) 

0 DOCUMENTATION (AND INTERPRETATION) IS SOMETIMES INCONSISTENT 

0 SOFTWARE DEVELOPMENT MUST BE MONITORED CLOSELY 

0 THOROUGH SYSTEM-LEVEL TESTING INCREASES PROBABILITY OF SUCCESS 

Figure 9 
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There is an awesome amount of documentation available to guide experiment 
developers. I have listed only a few that could provide a starting place for 
the newcomer. The references are available from the following sources: 

1. MSFC Spacelab Payload Project Office, Code JA11, 

Telephone (205) 453-2430. 

2. JSC Customer Service Center, Mail Code TC12, 

Telephone (713) 483-2337. 

3. Available from the authors. 

A list of key documents from reference 1 is included in this handout along 
with appendix A of reference 2. The lists identify some of the available 
documentation . 


REFERENCES 


1. STS INVESTIGATOR'S GUIDE - MSFC (205) <453-2430 

2. SHUTTLE/PAYLOAD INTEGRATION ACTIVITIES PLAN ( JSC-21000-IAP) (713) <483-2337 

3. FLYING A SCIENTIFIC EXPERIMENT ABOARD THE SPACE SHUTTLE - A PERSPECTIVE 
FROM THE VIEWPOINT OF THE EXPERIMENTER BY WARREN D. HYPES. NASA LANGLEY 
AND JOSEPH C. CASAS, OLD DOMINION UNIVERSITY RESEARCH FOUNDATION 
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Appendix A 

Referenced Documents List 


Copies of the documents listed below may be obtained by mail or telephone 
request from: 


Customer Service Center 
Mail Code TC12 

NASA Lyndon B. Johnson Space Center 
Houston, TX 77058 

713-483-2337 


Standard Integration Plans 

Standard Integration Plan for Payloads Using Small Payload 
Accommodations, JSC-21000-SIP-SML 

ShuttlelPayload Standard Integration Plan forSpacelab Payload (Generic), 
JSC-21 00 1-SIP-SLB 

Standard Integration Plan for Payloads Using Standard Accommodations 
(Deployable), JSC-21 002-SIP-DEP 

Standard Integration Plan for Payloads Using Middeck-Type Payload 
Accommodations, JSC-2 1 003-SIP-MDK 

Standard Integration Plan for Payloads Using Standard Accommodations 
(Attached). JSC-2 1 004-SI P-ATT 

Shuttle/Payload Standard Integration Plan for Payload Specialist Payloads, 
JSC-2 1005-SIP-PSP 

Shuttle/Payload Standard Integration Plan for DOD Deployable! Retrievable- 
Type Payloads, JSC-2 1006-SIP-DOD 


Interface Definition Documents 

Shuttle/Payload Interface Definition Document for Small Payload 
Accommodations, JSC-2 1000-IDD-SML 

Shuttle/Payload Interface Definition Document for Middeck Payload 
Accommodations, JSC-2 1003-IDD-MDK 
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Shuttle/Payload Interface Definition Document for Standard 
Accommodations, JSC-21 004-IDD-STD 

Miscellaneous Documents 

Space Transportation System Customer Accommodations Document, 
JSC-21000-HBK 

Shuttle EVA Description and Design Criteria, JSC- 10615 

KSC Launch Site Accommodations Handbook for STS Payloads, K-STSM-14. 1 

Space Transportation System Reimbursement Guide, JSC-1 1802 

NSTS Optional Services Pricing Manual, JSC-20109 

Payload Operations Control Center Capabilities Document, JSC- 1 4433 

Safety Policy and Requirements for Payloads Using the STS, NHB 1 700 7 

Implementation Procedures for STS Payloads System Safety Requirements, 
JSC-13830 

Mission Integration Control Board Configuration Management Procedures, 
JSC- 18468 
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Key Documents & References 


Attached Shuttle Payload Carriers Notes: 

Brochure provided by NASA/GSFC, Greenbch, MD 

20771 

Microgravity Science and Applications - 

Experiment Apparatus and Facilities 

Brochure produced by NASA/MSFC Marshall Space 

Flight Center, AL 35812 

Guide to the Life Sciences Flight 
Experiments Program 

Produced by NASA Life Sciences Flight Programs 

Branch at NASA Headquarters, Washington, DC 

20546 

User’s Guide to Spacelab Payload Processing 

Produced by Cargo Projects Office, NASA/KSC, — 

Florida 32899 

STS User Handbook 

NASA Headquarters, Washington DC 20546 

Launch Site Accommodations Handbook 

for STS Payloads 

NASA/KSC Document, K-STSM-14.1 

The User’s Guide to Spacelab Payload Processing 

Brochure provided by NASA/KSC, Florida 32899 ~ ~ “ 

Mission Requirements on Facilities/Instruments/ 

Experiments for STS Attached Payloads (MROFIE) 

MSFC JA-447 

Payload Flight Equipment Requirements 

for Safety-Critical Structures 

MSFC JA-418 

Payload Developer’s Guide for 

Launch Site Operations “ 

KSC IV 0018.0 

Spacelab Payload Accommodations Handbook (SPAH) 

SLP/2104 

Space Shuttle System Payload Accommodations 

JSC 07700, Vol. XIV 

Safety Policy and Requirements 

for Payloads Using the STS 

NHB 1700.7A 

Orbiter Middeck Payload Provisions Handbook 

JSC-16536 

STS Payload Safety Guidelines Handbook 

JSC 11123 

POCC Capability Document 

JSC-14433 

“Flying a Scientific Experiment Aboard the Space 

Shuttle - A Perspective from the Viewpoint of the 

Experimenter, ’ ’ 

A Technical Paper by Warren Hypen (NASA/LaRC) 

and Joseph C. Casas (Old Dominion University 

Research Foundation, Norfolk, Virginia) 
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